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PREFACE 



Data Catalogue 2 operates under control of the following 
operating systems: 

® 
NOS 1 for the CONTROL DATA CYBER 170 

Series; CYBER 70 Models 71, 72, 75, and 74; and 6000 

Series Connputer Systems. 

® 
NOS/BE 1 for the CDC CYBER 170 Series; 

CYBER 70 Models 71, 72, 73, and 74; and 6000 Series 

Computer Systems. 



Data Catalogue 2 is a CDC modification of the product 
designed and developed by Synergetics Corporation. 

This manual describes the Utility function of Data 
Catalogue. It is assumed that the user of this manual is 
familiar with the information in the Data Catalogue 
reference manual and with the operating system under 
which Data Catalogue 2 is operating. Related material Is 
contained in the publications listed below. 



Publication 

CYBER Record Manager Advanced 
Access Methods Version 2 
Reference Manual 



Publication Number 



60499300 



Data Catalogue 2 
Reference Manual 

NOS Version 1 Reference Manual 
Volume 1 of 2 

NOS Version 1 Reference Manual, 
Volume 2 of 2 

NOS/BE Version 1 Reference Manual 



60483200 
60435400 
60445300 
60493800 



CDC manuals can be ordered from Control Data Corporation, Literature and 
Distribution Services, 308 North Dale Street, St. Paul, Minnesota 55103. 



This product is intended for use only as described in 
this document. Control Data cannot be responsible 
for the proper functioning of undescribed features or 
parameters. 
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NOTATIONS USED IN THIS MANUAL 



UPPERCASE 



UPPERCASE 



[] 

Brackets 



Words are Data Catalogue 
reserved words. They must be 
spelled correctly including any 
hyphens. 

Underlined uppercase words are 
required when the format in 
which they appear is used. When 
a portion of a word is under- 
lined, either the underlined 
portion or the entire word can 
be used. 



Optional portion of a format. 
All of the format within the 
brackets can be omitted or 
included at user option. If 



u 

Braces 



Ellipses 



items are stacked vertically 
within brackets, only one of 
the stacked items can be used. 



Portion of a format in which 
one, and only one, of the 
vertically stacked items must 
be used. Braces are also used 
to enclose the portion of a 
required entry that can be 
repeated. 

Repetition indicator. Portion 
of the format enclosed in the 
immediately preceding braces or 
brackets can be repeated at 
user option. 
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INTRODUCTION 



Data Catalogue is a computerized tool for documenting 
the information processing function. It produces a 
Catalogue that is a dictionary of data, procedures, and 
users. The Catalogue is a central repository where 
information processing documentation can be maintained, 
accessed, retrieved, and distributed at computer speeds. 

The individual charged with the responsibility of the 
operational use and control of the Catalogue is referred to 
as the data administrator in the Data Catalogue reference 
manuals. Information that should be restricted to the 
data administrator is provided in this manual. Information 
related to general maintenance and use of the Catalogue 
is detailed in the Data Catalogue reference manual. 

The data administrator manages the Data Catalogue 
system and has a major impact on the success of its use at 
the installation. How the system is to be used in a 
specific environment, which optional features are to be 
implemented, and what procedures are to be used are 
decisions made by the data administrator. 

One of the first responsibilities is to initiate the 
Catalogue. This involves determining the space 
requirements for the Catalogue files, identifying the 
installation, and selecting optional features. Once the 
Catalogue has been initiated, the data administrator plans 
strategies to convert files, to implement procedures, and 
to integrate the use of the Catalogue into the system life 
cycle. 

The Utility function is a data administrator function that 
is provided to help meet some of these responsibilities. 
This function is only summarized in the Data Catalogue 
reference manual and is detailed in this separate manual 
in order to preserve the confidentiality of some of the 
privileged facilities made available through the Utility 
function. 



DATA ADMINISTRATOR FACILITIES 

The Utility function provides the data administrator with 
the facilities to perform the following operations: 

Initialize the system. 

Define sensitive fields. 

Transfer entries between Catalogues. 

Backup and restore the Catalogue master files. 

Manage entries. 

Display system statistics. 

These operations are briefly described in this section. The 
use of the Utility function to implement the facilities that 
perform these operations is described in subsequent 
sections. 



SYSTEM INITIALIZATION 

Before Data Catalogue can be used, the system must be 
initialized. Initialization involves identifying the 
installation and providing estimates of the file space to be 
reserved for the Catalogue master files. 

The required steps in the initialization process are as 
follows: 

Identify the installation. 

Provide the installation address. 

Specify the number of home blocks for the direct 
access files in the Catalogue. 

Optional steps in the initialization process are as follows: 

Define sensitive fields. 

Specify page overflow control and end-of-page 
messages. 

Optional features can be activated, changed, or 
deactivated after initialization. The Utility function is 
used for both required and optional procedures. 



SENSITIVE FIELD DEFINITION 

Entities in the Catalogue are defined by specifying values 
for one or more fields in various categories of 
information. An element, for example, can be defined by 
completing up to nine different categories of 
information. Each of these categories can contain one or 
many fields. 

As procedures for the use of Data Catalogue are 
established, minimum requirements for different entity 
types can be determined. These requirements can be 
defined to Data Catalogue by describing certain fields as 
sensitive fields. This sets up an entry in the Catalogue 
control file;, the entry can then be monitored by Data 
Catalogue. 



TRANSFER OF ENTRIES 

In most cases, at least two separate Catalogues are 
maintained. The primary Catalogue is a current 
Catalogue containing all the data pertaining to the 
installation's data resource. This Catalogue can be 
referred to as the production Catalogue. 

A second Catalogue can be maintained to hold entries that 
are in varying stages of development. This Catalogue, 
which can be referred to as the test Catalogue, contains 
the evolving definitions from all ongoing projects. As a 
project Is completed and the definitions are finished, the 
entries can be transferred from the test Catalogue to the 
production Catalogue. When the transfer occurs, the test 
Catalogue entry can be deleted or it can remain in the 
test Catalogue. 
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This facility provides the means to handle any number of 
Catalogues to meet distributed processing needs or 
divisional requirements. Entry transfers can be made 
from any Catalogue to any other Catalogue. 
Production-to-test Catalogue transfers can occur as w^ell 
as test-to-production Catalogue transfers. 



BACKUP AND RESTORE FILES 

System integrity can be preserved in several vtrays. Good 
procedures to encourage controlled use of Data Catalogue 
minimize accidental system disasters. Plans must also be 
made for occasional machine or system malfunctions that 
could have a negative impact on the Catalogue files. 
When bacl<up files are available, the Catalogue can be 
restored after a system failure. 

When the operator succeeds in interrupting the system 
before a Catalogue addition or deletion is synchronized on 
the data and relational files, a situation exists w/here the 
files are not internally consistent. To protect against this 
eventuality, it is recommended that bacl<up of the 
Catalogue files be performed at reasonable intervals. 

Initially, the volume of additions to the Catalogue is high, 
and backup procedures w/ill probably be performed 
frequently. As the Catalogue stabilizes, the frequency of 
bacl<up mil drop. 

The backup and restore facilities of the Utility function 
produce control totals of the quantity of entries by entity 
type. The data administrator can thus keep abreast of the 
number of entities (elements, records, files, users, etc.) 
that are defined in the Catalogue. 



ENTRY MANAGEMENT 

Management of entries in the Catalogue has many facets. 
Each Catalogue entry has a unique system key, a 
Catalogue name. It is this name by which an entry is 
identified and accessed. An entry contains categories of 
information; each category can contain lines of data in 
which one or more fields are defined. 

Entry management is accomplished through the following 
Data Catalogue functions: 

Utility 

Query 

Report 

Update 

The use of these functions by the data administrator in 
managing entries is discussed briefly in the following 
paragraphs. The Utility function is detailed in this 
manual. The other functions are detailed in the Data 
Catalogue reference manual. 



Utility Function 

Entry management through the Utility function involves 
renaming entries and renumbering lines in entries. 
Renaming an entry means that the current Catalogue 
name (system key) is replaced with a new Catalogue 
name. AH references to the current Catalogue name can 
be either changed to the new Catalogue name or retained 
with the current Catalogue name. t 



The numbering sequence for category lines in an entry can 
be changed when lines need to be inserted and line 
numbers are not available. For example, five lines have 
been entered in increments of one, and two lines need to 
be inserted between lines 3 and 4. The renumber facility 
can be used to change the existing line numbers so that 
the numbers are in increments of ten; the five lines can 
then be inserted in the appropriate place. 



Query Function 

Alternative forms of entry management are provided by 
the Query function. The data administrator can 
determine which entries meet certain criteria such as: 

Missing categories of information 

Existing categories of information 

Changed in a given revision 

Never been changed 

Related to specific entries 

Not related to other entries 

Counts, lists, or detailed reports of these entries can be 
obtained by the data administrator. 



Report Function 

Facilities of the Report function also promote entry 
management. Key reports for the data administrator are: 



Relational Report 
entries. 



shows relationships between 



Name Analysis Report - lists Catalogue names that 
can be scanned for redundancies. 



Catalogue Report 
Catalogue entries. 



details the information stored in 



Three other reports are also available and will probably be 
used by the data administrator at times. These are the 
Hierarchy, Usage, and Index Reports. A plan should be 
developed for the regular use of some reports and the 
integration of other reports as project tools. 



Update Function 

The primary means for entry management is provided by 
the Update function. Entries are added, changed, and 
deleted through the use of this function. Combined with 
the facilities of the Utility function, the data 
administrator can change any entry defined in the 
Catalogue. 



STATISTICS DISPLAY 

The display facility of the Utility function provides the 
data administrator with various system statistics. This 
facility can be used to display the following statistics: 

Date of last update and number of entries added and 
deleted 

Date of last backup and number of entries involved 
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Date of last restore and number of entries involved 

Fields defined as sensitive 

Current number of lines per page 

This information, along with the audit trails produced by 
the functions, adds to the ability of the data administrator 
to manage the data resource. Direct access file statistics 
produced by CYBER Record Manager are also available to 
obtain the amount of space available for expansion. 

DATA ADMINISTRATOR 
CONSIDERATIONS 

Many aspects of data administration interface w/ith the 
use of Data Catalogue. Most of these require a decision 
by the data administrator. Some topics for consideration 
are presented in the follow/ing paragraphs. These are 
intended to provide a frame of reference for the 
individual requirements of an installation. In some cases, 
Data Catalogue places a constraint on the options 
available; in these cases, the constraint is made clear. 

NAMING CONVENTIONS 

Data Catalogue requires a unique Catalogue name for 
each entry. The name is limited to 32 characters. It can 
consist of alphabetic characters, the digits zero through 
nine, and the special characters dash and underscore. No 
other characters can be specified in a Catalogue name. 

The Catalogue name is not the only name available for an 
entry. The NAMES category in an entry can be used to 
store a COBOL data name, a PL/I identifier, and a TOTAL 
DBMS name. The free-form description field can also be 
used to store an expanded name. 

In most cases, the Catalogue name is the common name 
for the entry. This name should be w/idely intelligible and 
as unambiguous as possible; it must be unique within the 
Catalogue. The COBOL data name is frequently used for 
the Catalogue name. This is useful in propagating an 
acceptable name for all programmers. The PL/I identifier 
can be used in the same way for PL/I installations. 



DATA ENTITY REQUIREMENTS 

Several types of data entities can be defined to Data 
Catalogue. These include: 

Elements 

Groups 

Riecords 

Files 

TOTAL data bases 

TOTAL datasets 

Once it has been established which data entity types are 
to be defined, each entity type should be reviewed to 
determine the categories that are to be used. The 
individual categories should then be reviewed to decide on 
the applicability of fields within the categories. A field 
can be established as: 



Mandatory; it is defined as sensitive. 

Desirable; it is useful, but optional. 

Inappropriate; it is not applicable to the installation. 

This review of entity types, categories, and fields enables 
the data administrator to initially tailor the Catalogue 
according to individual purposes. 

PROCEDURE ENTITY REQUIREMENTS 

Procedure entity types that can be defined to Data 
Catalogue include: 

Forms 

Reports 

External resources 

Programs and modules 

Manual tasks 

Systems 

These entity types should be reviewed in the same manner 
as data entity types. Mandatory (sensitive), optional, and 
inappropriate fields in applicable categories should be 
determined for each procedure entity type. 



USER ENTITY REQUIREMENTS 

The user entity type should be reviewed to determine 
whether or not it is appropriate for the Catalogue. If user 
entities are to be defined, categories and fields should be 
reviewed in the same manner as for data entity types to 
establish requirements. 



CATALOGUE LOADING 

The initial information to be loaded into the Catalogue is 
a critical issue. The value of the Catalogue is directly 
related to the quantity and quality of information stored 
in it. A carefully drawn plan for implementing the 
Catalogue over a specific period of time usually ensures 
that both quantity and quality considerations are 
addressed. 

A conversion plan could be set up, for example, over a 
period of a year. In this year, several sequential 
objectives can be established. The first requirement could 
be to define all data entities covering the three most 
critical applications. This is set up as a planned campaign 
to return as much value from the Catalogue as possible in 
the shortest time period. 

In addition to converting the most critical applications, 
priorities for conversion of other significant data 
resources can be established. The actual time required to 
load the Catalogue with application information is heavily 
dependent on the decisions made concerning the amount 
of data considered mandatory and the availability of that 
data. In some installations, an accurate up-to-date body 
of data for critical applications can be readily converted. 
In other installations, little information is available and 
the research required is substantial. 
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The Convert function can be an effective means of w/hether the information obtained by the Convert function 

capturing sl<eletal definitions by scanning source provides a useful amount of preliminary data or is too 

programs. The programs should be reviewed to determine sl<etchy to repay the effort involved. 
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SYSTEM INITIATION 



Data Catalogue must be initiated before it can be used. 
This process tailors the system in terms of its 
identification, space requirements, and some optional 
selections. Optional features that can be selected include 
sensitive (required) fields, lines per page, and end-of-page 
message. 

INITIATION REQUEST STRUCTURE 

The utility request to initiate the system consists of a 
series of statements that provide the required information 
and select desired options. 

Six statements can be included in a Utility request at 
system initiation time; 

$UTILITY 

Specifies a Utility request for system initiation. 
NAME 

Identifies the installation. 
ADDRESS 

Specifies the installation address. 

HMB 

Specifies the number of home blocks for the 
direct access files in the Catalogue. 

LINES 

Indicates the number of lines per page. 
ENDMSG 

Specifies an end-of-page message. 

The lUTILITY, NAME, ADDRESS, and HMB statements 
are required for system initiation; no default values exist 
for these statements. The LINES and ENDMSG 
statements are optional. 

A sequence number can be entered in columns 73 through 
80 in any statement when the request is submitted on 
punched cards. Sequence numbers are not checked by 
Data Catalogue. 

Figure 2-1 shows the deck structure of a Utility request 
for initiating the system. 





y 








■^ENDMSG 








^LINES 








^HMB 








^ADDRESS 










^IMAME 










/SUTILITY 








^ 















Figure 2-1. Utility Request Deck Setup, System Initiation 



$UTILITY INITIATE 



Figure 2-2. $UTILITY Statement Format, 
Utility Initiation Request 



NAME STATEMENT 

The NAME statement specifies the name of the 
installation. The specified name is printed at the top of 
each page output by Data Catalogue. The format of the 
NAME statement is shown in figure 2-3. 

The single phrase in the NAME statement is defined as 
follows; 

user-name 

Name identifying the installation. 

The following rules are applicable to the NAME statement: 

The statement cannot be continued onto a second line. 

The specified user-name can be a maximum of 27 
characters. 

The NAME statement is required and must 
immediately follow the $UTILITY statement. 



$UTiLITY STATEMENT 

The $UTILITY statement is required to initiate the Utility 
request. Only one can be specified in the Utility request. 
The format of the $UTILITY statement for system 
initiation is shown in figure 2-2. 

This statement must be the first statement in the Utility 
request. The keyword INITIATE indicates that the Utility 
request is the first Data Catalogue function performed for 
the system. 



NAM E user-name 



Figure 2-3. NAME Statement Format, 
Utility Initiation Request 
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ADDRESS STATEMENT 

The ADDRESS statement specifies the address of the 

installation. It is a required statement for the Utility 

initiation request. The format of the ADDRESS 
statement is shown in figure 2-4. 

The single phrase in the ADDRESS statement is defined as 
follows: 

user-address 

Address of the installation identified by the 
NAME statement. 

The following rules are applicable to the ADDRESS 
statement; 

The statement cannot be continued onto a second line. 

The specified user-address can be a maximum of 27 
characters. 

The ADDRESS statement must immediately follow 
the NAME statement. 



Each block in the MASTl and MAST2 files can contain 
information about two entries. The number of home 
blocks to be specified in the HMB statement is determined 
based on the maximum number of expected Catalogue 
entries divided by two. This number should be rounded up 
to the next prime number to obtain optimum utilization of 
the hashing routine supplied by CYBER Record Manager. 

As entries are added to the Catalogue, statistics output by 
CYBER Record Manager should be monitored to track the 
number of overflow blocks created. When the number of 
overflow blocks becomes excessive, the following steps 
should be performed: 

Backup the files MASTl and MAST2 through the 
backup facility of the Utility function. 

Initiate the system with a new value for the HMB 
statement. 

Restore the MASTl and MAST2 files through the 
restore facility of the Utility function. 

Refer to the CYBER Record Manager reference manual 
for detailed information about direct access file statistics. 



ADDRESS user-address 



Figure 2-4. ADDRESS Statement Format, 
Utility Initiation Request 



LINES STATEMENT 

The number of lines to be printed on an output page can 
be specified by the LINES statement. Page overflow 
occurs when the specified number of lines is exceeded. 
The format of the LINES statement is shown in figure 2-6. 

The single phrase in the LINES statement is defined as 
follows: 



HMB STATEMENT 

The HMB statement is required to designate the number 
of home blocks to be allocated for each of the two direct 
access files in the Catalogue. The two direct access files 
are the data file (MASTl) and the relational file (MAST2). 
The control file (MAST3) is a word addressable file and 
always requires 123 blocks; user specification is not 
required for this file. The format of the HMB statement 
is shown in figure 2-5. 

The single phrase in the HMB statement is defined as 
follows: 



Number of home blocks to be preallocated for 
the MASTl file and the MAST2 file. 

The following rules are applicable to the HMB statement; 

The specified number ca(inot exceed five digits. 

The number of home blocks specified is preallocated 
for each of the files MASTl and MAST2. 

The HMB statement must immediately follow the 
ADDRESS statement. 



HMB=nnnnn 



Maximum number of lines to be printed on a 
page; default is 59 lines. '' 

The following rules are applicable to the LINES statement: 

The statement is optional; if it is included in the 
request, it must follow the HMB statement. 

A maximum of 99 lines per page can be specified. 



LINES nn 



Figure 2-6. LINES Statement Format, 
Utility Initiation Request 



ENDMSG STATEMENT 

The ENDMSG statement is an optional statement that is 
used to specify a message to be printed at the bottom of 
each standard report page. The format of the ENDMSG 
statement is shown in figure 2-7. 

The angle phrase in the ENDMSG statement is as follows; 

message 

Text for the message to appear at the end of 
report pages; default is no end of page message. 



Figure 2-5. HMB Statement Format 



2-2 
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The following rules are applicable to the ENDMSG 
statement: 

The statement is optional; if it is included in the 
request, it must follow the HMB or LINES statement. 

A maximum of 27 characters can be specified for the 
message; if the message is to be centered, it must be 
spaced accordingly within the 27 characters of the 
message phrase. 



ent-type 



END MSG message 



Figure 2-7. ENDMSG Statement Format, 
Utility Initiation Request 

SENSITIVE FIELD DEFINITION 

The data administrator can specify that certain fields in 
an entity definition are sensitive; that is, the fields are 
required to define the entity. Sensitive fields are 
monitored by Data Catalogue. 

ENTITY FIELDS 

Many fields are available to define an entity. Some fields 
are used as a matter of course. A particular field might 
be used in some cases and not used in other cases. 

In a test Catalogue situation, it probably would not be 
desirable to exclude any entries because of missing fields. 
When entries are transferred to the production Catalogue, 
however, minimum field requirements for an entity type 
can be established to ensure that the entry contains 
enough information to be useful. For example, all 
element entities could be required to have the length, 
format, and picture defined. If a subsequent Update 
request deletes a required field, a warning message is 
issued. 

STANDARDS STATEMENT 

Sensitive fields are defined to Data Catalogue by the 
STANDARDS statement. This is an optional statement; 
one statement can be included for each entity type. The 
format of the STANDARDS statement is shown in 
figure 2-8. 



STA NDARDS ent-type sysnam8= 



fYESi 
I NO f 



sy$name= 



tr}] 



Figure 2-8. STANDARDS Statement Format 



Phrases in the STANDARDS statement are defined as 
follows: 



Type of entity for which sensitive fields are to 
be established. Entity types that can be 
specified are as follows: 

ELEMENT 

GROUP 

RECORD 

FILE 

DATASET 

TOTAL 

MODULE 

TASK 

FORM 

EXTERNAL 

REPORT 

SYSTEM 

USER 



sysname= 



Values 



System name for a field to be required. 
that can be specified are as follows: 

YES 



The field is required for the entity 
definition. 

NO (default) 

The field is not required for the entity 
definition. This is normally specified to 
change a field previously specified as 
required to not required. 

The following rules are applicable to the STANDARDS 
statement: 

A separate statement is required for each entity type. 

A statement can be continued onto a second line. 
The first line must end with a comma; the 
continuation line must begin with two spaces followed 
by the next system name. 

STANDARDS statements can be included in Utility 
initiation or maintenance requests. 

Initial values for all fields are NO. After a field has 
been established as required, NO must be specified to 
remove the requirement. 

Abbreviations cannot be specified for the ent-type 
phrase; the full name for the entity type must be 
specified. 

A complete list of field system names for each entity type 
is in appendix D of the Data Catalogue reference manual. 

Only important fields should be established as required 
fields. This makes reporting of changes or absences much 
more important and eliminates reviewing volumes of low 
grade data. 

CHANGES TO INITIATION VALUES 

After system initiation, the data administrator might 
want to change some of the information originally 
supplied. This is accomplished through the maintenance 
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capability of the Utility function. Any value specified at 
system initiation, except the number of home blocks, can 
be changed in a Utility maintenance request. 

The number of home blocl<s allocated for the direct access 
files in the Catalogue can only be changed by reinitiating 
the system. If this becomes necessary, the backup facility 
must be used for the current Catalogue files. The system 
can then be reinitiated using the original procedure with a 
new HMB statement. Reinitiation is completed by 
performing the restore facility. 

Five statements can be included in a Utility maintenance 
request: 



$UTILITY 



Specifies a 
maintenance. 



Utility request for system 



NAME 

Changes the name identifying the installation. 
ADDRESS 

Changes the installation address. 
LINES 

Changes the number of lines per page. 
ENDMSG 

Specifies a new end-of-page message. 

The $UTILITY statement is required for a maintenance 
request. All other statements are optional. 

A sequence number can be entered in columns 73 
through 80 in any statement when the request is 
submitted on punched cards. Sequence nunDbers are not 
checked by Data Catalogue. 

$UTILITY STATEMENT 

The SUTILITY statement is required to initiate the Utility 
request. Only one statement can be specified in the 
Utility request. The format of the $UTILITY statement 
for system maintenance is shown in figure 2-9. 




Figure 2-9. $UTIL1TY Statement Format, 
Utility Maintenance Request 

This statement must be the first statement in the Utility 
request. The keyword MAINTENANCE indicates that the 
Utility request is for system maintenance. 

NAME STATEMENT 

The NAME statement is included in a Utility maintenance 
request to change the installation name specified at 
system initiation. The name can be changed without 
changing the installation address. The format of the 
NAME statement for a maintenance request is shown in 
figure 2-10. 




Figure 2-10. NAME Statement Format, 
Utility Maintenance Request 

The single phrase in the NAME statement is defined as 
follows; 

tiew-user-name 

New name by which the installation is to be 
identified. 

The following rules are applicable to the NAME statement: 

The statement cannot be continued onto a second line. 

The new-user-name can be a maximum of 27 
characters. 



ADDRESS STATEMENT 

The installation address defined to Data Catalogue can be 
changed by a Utility maintenance request. The address 
can be changed without changing the installation name. 
The format of the ADDRESS statement Is shown in 
figure 2-11. 



ADD RESS new-^ser-address 



Figure 2-11. ADDRESS Statement Format, 
Utility Maintenance Request 

The ADDRESS statement has one phrase, which is defined 
as follows: 

new-user-address 

New address for the installation. 

The following rules are applicable to the ADDRESS 
statement: 

The statement cannot be continued onto a second line. 

The new-user-address can be a maximum of 27 
characters. 



LINES STATEMENT 

The number of lines for an output page can be changed 
after system initiation by including the LINES statement 
in a Utility maintenance request. The format of the 
LINES statement is shown in figure 2-12. 



LINES nn 



Figure 2-12. LINES Statement Format, 
Utility Maintenance Request 
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The LINES statement contains one phrase, which is 
defined as follows: 



The phrases that can be specified in the ENDMSG 
statement are defined as follows: 



nn 



New maximum number of lines per page. 



The following rules are applicable to the LINES statement: 
The number of lines specified can be up to 99 lines. 

If the number of lines was specified at system 
initiation and the default of 59 lines is to be used, 
LINES 59 must be specified in a Utility maintenance 
request. 



ENDMSG STATEMENT 

The ENDMSG statement can be included in a Utility 
maintenance request to specify an end-of-page message or 
to delete an end-of-page message previously specified. 
The format of the ENDMSG statement is shown in 
figure 2-13. 



ENDMSG 



( new-message ( 
(NONE ) 



Figure 2-13. ENDMSG Statement Format, 
Utility Maintenance Request 



new-message 

New text for the message to appear at the end of 
report pages. 

NONE 

Deletion of the end-of-page message previously 
specified; no message is printed at the end of 
report pages. 

The following rules are applicable to the ENDMSG 
statement: 

If new-message is specified, the message can contain 
up to 27 characters. 

A message to be centered must be spaced accordingly 
within the 27 characters of the new-message phrase. 



AUDIT REPORT 

A Data Administrator Utility Report is output by the 
Utility function. All statements in the Utility request are 
listed in this report. Any error discovered in scanning the 
statements is listed immediately below the statement in 
error. Refer to appendix B for a complete list of 
diagnostics output by the Utility function. 

Successful completion of the initiation process is 
indicated by the following message on the Data 
Administrator Utility Report: 

DATA CATALOGUE FILES HAVE BEEN INITIATED 
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CATALOGUE MAINTENANCE FACILITIES 



The data administrator has certain administrative 
responsibilities for the Catalogue. The Utility function 
provides a series of statements to carry out these 
responsibilities. Maintenance facilities include: 

Backup and restore the Catalogue master files. 

Copy and move entries betw/een Catalogues. 

Rename entries and renumber category lines. 

Display system statistics. 

BACKUP AND RESTORE FACILITIES 

A backup copy of the Catalogue files should be maintained 
to ensure that the files are not completely lost or 
destroyed. In case of a system failure, the backup copy of 
the files can be used to restore the Catalogue. The 
operating system file management copy features can be 
used to backup and restore the files. The Data Catalogue 
Utility function also provides facilities to backup and 
restore the Catalogue. 



The backup facility produces sequential files from the 
Catalogue files. It also generates the Backup Audit 
Report, w^hich contains totals for each entity type. 

The restore facility uses the sequential files created by 
the backup facility to reload the Catalogue files. As the 
files are restored, they are reorganized so as to improve 
throughput. The restore facility also generates a Restore 
Audit Report, which is identical in format to the Backup 
Audit Report. 



BACKUP STATEMENT 

The BACKUP statement is included in a Utility request to 
produce an archive copy of the Catalogue files. The 
format of the BACKUP statement is shown in figure 3-1. 



BACKUP {^} 



GENERAL CONSIDERATIONS 

The backup and restore facilities of the Utility function 
can be used under various conditions. The backup facility 
should be used frequently when the Catalogue is very 
volatile. When the Catalogue is in the early stages of 
development, the backup facility should be used after 
every update. As the volume of Update requests 
decreases, the need to backup the files also decreases. 

The backup and restore facilities are used for the 
Catalogue data file (MASTl), relational file (MAST2), and 
control file (MA5T3), The data file contains the entity 
definitions; the relational file contains pointers between 
entries; and the control file contains data identifying the 
system, the sensitive fields, and other installation- 
dependent information. The backup and restore facilities 
are performed either on all three files or on only the data 
and relational files. 

Backup and restore of the Catalogue can be accomplished 
in two ways. The operating system COPY facilities should 
be used for simple copy operations, which occur when only 
an archive copy of the Catalogue is required. The backup 
and restore facilities of the Utility function are used to 
produce archive copies, to reorganize the files MASTl and 
MAST2, and to produce Catalogue master file reports. 

The backup and restore facilities need be used only when 
the following requirements exist: 

The direct access files (MASTl and MAST2) contain 
an unacceptable number of overflow blocks. The 
system must be re-initiated with a new value for the 
number of home blocks. 

All existing Catalogue entries need to be moved to a 
new Catalogue. 

A report of the total number of records and entries 
for each entity type is desired. 



Figure 3-1. BACKUP Statement Format 

Phrases in the BACKUP statement are defined as follows; 

DATA 

Backup the data file (MASTl) and the relational 
file(MAST2). 

ALL 

Backup the data file (MASTl), the relational file 
(MAST2), and the control file (MAST3). 

The following rules are applicable to the BACKUP 
statement: 

The files to be backed up must be specified by the 
DATA or ALL phrase. 

The statement can be executed whenever information 
is entered or changed in the Catalogue files. 



RESTORE STATEMENT 

The RESTORE statement is Included in a Utility request 
to recreate the Catalogue files from the sequential files 
produced by the BACKUP statement. The format of the 
RESTORE statement is shown in figure 3-2. 



RESTORE {^} 



Figure 3-2. RESTORE Statement Format 
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Phrases in the RESTORE statement are defined as follows: 



DATA 



Restore the data file (MASTl) and the relational 
file (MAST2). 

ALL 

Restore the data file (MASTl), the relational file 
(MAST2), and the control file (MAST3). 

The following rules are applicable to the RESTORE 
statement: 

The files to be restored must be specified by the 
DATA or ALL phrase. 

The Utility initiation request must be executed 
before the restore operation can be executed. 

If the control file (MAST3) is not restored, it contains 
initiation values. The old run statistics, sensitive field 
definitions, and original initiation values are lost. This is 
desirable when an existing Catalogue is being moved to a 
new Catalogue. 

If the control file (MAST3) is being restored, it contains 
the old run statistics, sensitive field definitions, and 
original initiation values. The number of home blocks, 
however, is the number specified in the immediately 
preceding initiation request. This approach is used when 
it becomes necessary to reorganize the existing Catalogue. 



COPY AND MOVE FACILITIES 

Many Data Catalogue users maintain separate Catalogues 
for developmental or test use and for production use. 
Some users have several Catalogues to meet divisional or 
other distributed responsibilities. 

The communication between Catalogues generally 
involves the transfer of an entry from one Catalogue (the 
source) to another (the destination). The transfer is 
sometimes a test-to-production Catalogue transfer and 
sometimes a production-to-test Catalogue transfer. 

GENERAL CONSIDERATIONS 

Two types of transfer can be accomplished. A copy 
transfer retains the entry in the original (source) 
Catalogue. A move transfer deletes the entry from the 
original Catalogue. 

Transfer is normally performed for individual entries. 
Element entries, for example, are usually transferred to 
the production Catalogue as they become fully defined 
during the course of a project. This enables the 
definitions to be used in a wider environment as early as 
possible. At a later time, the record, file, and other 
higher entity types^can be transferred. 

Sometimes it is desirable to transfer a hierarchy of 
entries from one Catalogue to another. When this option 
is selected for a copy or move operation, the named entry 
and all its component entries are transferred at the same 
time. 



Any number of Catalogues can be established. Only two 
Catalogues can communicate with one another at one 
time. 



COPY STATEMENT 

The COPY statement is used to reproduce an entry from 
one Catalogue onto another Catalogue. When the copy 
operation is complete, the entry is stored in both 
Catalogues. The format of the COPY statement is shown 
in figure 3-3. 



COPY {^«„^RCHY|^^^„^^^., 



N EWN AM E=catname 



-] 



REV-NO= 



( NO-CHK \"] 






H^}] 



^j 



USER=uuu 



EDIT-ONLY= 



■W)] 



Figure 3-3. COPY Statement Format 

Phrases in the COPY statement are defined as follows: 

HIERARCHY or ENTRY 

Type of copy operation. HIERARCHY specifies 
that the lower-level components of the named 
entry are also to be transferred. ENTRY 
specifies that only the named entry is to be 
transferred. 

catname-1 

Catalogue name of the entry to be transferred to 
the new Catalogue. 

NEWNAME=catname-2 

New Catalogue name to be assigned to the entry 
in the destination Catalogue. 

USER=uuu 

User identifier; default is no user identifier. The 
three-character identifier is stored for each 
transferred entry. 

REV-NO= 

Revision number; generates revision number 
checking through the Update function. Values 
that can be specified are as follows: 

NO-CHK 

The file revision number is not checked. 

nnn 

The file revision number is to be 
validated. 
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EDIT-ONLY= 



Edit-only mode for the transfer. Values that can 
be specified are as follows: 

YES 

The entries are not transferred to the 
new Catalogue; the entries are edited 
for errors. 

NO (default) 

The entries are transferred to the new 
Catalogue; this ensures a permanent 
update of the new Catalogue. 



LIST= 

Formatted listing of the transactions that update 
the Catalogue to which the entries are 
transferred. Values that can be specified are as 
follows: 

YES 

A listing is generated. 
NO (default) 

A listing is not generated. 

The following rules are applicable to the COPY statement: 

The COPY statement must identify the entry or 
hierarchy of entries to be transferred. 

The statement can be continued onto a second line; 
the first line must end with a comma. 

The entry name specified for catname-1 must be a 
valid name in the source Catalogue; that is, it must 
identify an existing entry. 

The entry name specified for catname-2 must be a 
valid name in the destination Catalogue; that is, it 
must be a name not already existing within the 
Catalogue. 

MOVE STATEMENT 

The MOVE statement is the same as the COPY statement 
except that the entry is deleted from the original (source) 
Catalogue. When the move operation is complete, the 
entry is available only in the Catalogue to which it was 
moved (destination Catalogue). The format of the MOVE 
statement is shown in figure 3-4. 



Phrases in the MOVE statement are defined as follows: 

HIERARCHY or ENTRY 

Type of move operation. HIERARCHY specifies 
that the lower-level components of the named 
entry are also to be transferred. ENTRY 
specifies that only the named entry is to be 
transferred. 

catname-1 

Catalogue name of the entry to be transferred to 
the new Catalogue. 

NEWNAME=catname-2 

New Catalogue name to be assigned to the entry 
in the destination Catalogue. 

USER=uuu 

User identifier; default is no user identifier. The 
three-character identifier is stored for each 
transferred entry. 

REV-NO= 

Revision number; generates revision number 
checking through the Update function. Values 
that can be specified are as follows: 

NO-CHK 

The file revision number is not checked. 

nnn 

The file revision number is to be 
validated. 

EDIT-ONLY= 

Edit-only mode for the transfer. Values that can 
be specified are as follows; 



YES 



The entries are not transferred to the 
new Catalogue; the entries are edited 
for errors. 



NO (default) 



The entries are transferred to the new 
Catalogue; this ensures a permanent 
update of the new Catalogue. 



MOYi {yii«^RCHY|^^„,^., 



NEWNAME»catname-2 USER=uuu 



•J [ uSER= uuu] 



Figure 3-4. MOVE Statement Format 
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LIST= 

Formatted listing of the transactions that update 
the Catalogue to which the definitions are 
transferred. Values that can be specified are as 
follows: 

YES 

A listing is generated. 
NO (default) 

A listing is not generated. 

The following rules are applicable to the MOVE statement: 

The MOVE statement must identify the entry or 
hierarchy of entries to be transferred. 

The statement can be continued onto a second line; 
the first line must end with a comma. 

The entry name specified for catname-1 must be a 
valid name in the source Catalogue; that is, it must 
identify an existing entry. 

The entry name specified for catname-2 must be a 
valid name in the destination Catalogue; that is, it 
must be a name not already existing within the 
Catalogue. 

RENAME AND RENUMBER FACILITIES 

Data Catalogue entries are all identified by unique 
Catalogue names. Within an entry, category line numbers 
are used in some categories that require more than one 
category line. Facilities are provided for the data 
administrator to change Catalogue names and category 
line numbers. 

GENERAL CONSIDERATIONS 

After an entry has been stored in the Catalogue, it 
sometimes becomes desirable to change the Catalogue 
name. This can occur when the Catalogue name of an 
existing entry is more appropriate for a new entry to be 
added to the Catalogue. Renaming of Catalogue entries 
can also occur after scanning existing Catalogue names; 
some Catalogue names might not conform to a 
newly-established standard or convention. 

The number sequence used for category lines sometimes 
needs to be rearranged. For example, the DESCRIPTION 
category in an entry could need information inserted 
between lines 9 and 10. Renumbering category lines can 
often be avoided by assigning line numbers in increments 
greater than one; line number values up to 9999 can be 
used. 



RENAME STATEMENT 

The RENAME statement changes the Catalogue name 
assigned to an existing entry. The format of the RENAME 
statement is shown in figure 3-5. 



REN AME CATNAME=catname-1, N EWN AM E=catname-2 
[,DELETEOUD={g^}] [.CHGREFS= {|f }] 



Figure 3-5. RENAME Statement Format 

Phrases in the RENAME statement are defined as follows: 

CATNAME=catname-l 

Catalogue name of the entry to be renamed. 

NEWNAME=catname-2 

New Catalogue name to be assigned to the 
existing entry. 

DELETEOLD= 

Delete or retain entry with original Catalogue 
name. Values that can be specified are as 
follows: 

YES (default) 

Delete the existing Catalogue name; 
the entry is available only under the 
new name specified by catname-2. 



NO 



Retain the entry with the original 
Catalogue name and create a new entry 
with the new Catalogue name. The 
definition can be accessed by either 
Catalogue name. 



CHGREF5= 



Change or do not change references to the 
original name (catname-1). Values that can be 
specified are as follows: 

YES (default) 



All references to catname-1 
changed to refer to catname-2. 



are 



NO 



References to catname-1 are not 
changed; this is normally used in 
conjunction with DELETEOLD=NO. 

The following rules are applicable to the RENAME 
statement: 

The CATNAME and NEWNAME phrases are required; 
the other phrases are optional. 

The statement can be continued onto another line. 
The line to be continued must end with a comma; the 
continuation statement line must begin with two 
spaces followed by the next phrase of the statement. 
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NUMBER STATEMENT 

Category line numbers for an entry can be reallocated by 
the NUMBER statement. This statement is usually 
specified for an entry category that requires category line 
insertions when existing line numbers do not allow lines to 
be inserted. The format of the NUMBER statement is 
shown in figure 3-6. 

Phrases in the NUMBER statement are defined as follows; 

CATNAME=catname-l 

Catalogue name of the entry to be renumbered. 

CATEGORY= 

Category within the specified entry to be 
renumbered. Values that can be specified are as 
follows: 



ALL 



All categories in the specified entry are 
to be renumbered. 



category 



The category lines within the specified 
category are to be renumbered. 
Appendix D in the Data Catalogue 
reference manual lists valid categories 
for each entity type. 



BY=iiii 



Increment number for renumbering the lines; 
default is 5. 



FROM=mmmm 

First category line number to be renumbered; 
cannot be used if CATEGORY=ALL is specified. 

TOLINE=tttt 

Last category line number to be renumbered; 
cannot be used if CATEGORY=ALL is specified. 

STARTLINE=bbbb 

Value for first line number in the series to be 
renumbered. 

DISPLAY FACIIITY 

Data Catalogue provides many means of reporting 
statistics. Each function request that is executed 



produces some type of statistical report. In addition, the 
Utility function can request a display of certain system 
statistics. 

GENERAL CONSIDERATIONS 

The Utility function can be used to request a display of 
statistics that are useful in managing the Catalogue. 
These statistics are requested through the DISPLAY 
statement of the Utility function. 



DISPLAY STATEMENT 

The DISPLAY statement is a data management facility 
statement that provides statistical information. The 
format of the DISPLAY statement is shown in figure 3-7. 



DISPLAY 



UPDATE 
BACKUP 
RESTORE 
STANDARDS I 
LINES 



Figure 3-7. DISPLAY Statement Format 

Phrases in the DISPLAY statement are defined as follows: 

UPDATE 

Display date of last update and number of entries 
added and deleted by that update. 

BACKUP 

Display date of last backup and total number of 
entries involved in the backup. 

RESTORE 

Display date of last restore and total number of 
entries involved in the restore. 

STANDARDS 

Display all fields defined ' as sensitive 
(mandatory). 



LINES 



Display number of lines per page currently in 
effect. 



NUMBER CATNAME=catname-1 


[,CATEGORV={A^^j] 


[, BY=iiii] [. FROM=mmmml 


I. TOLINE=tttt] 




[, STARTLINE'bbbb] 









Figure 3-6. NUMBER Statement Format 
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OPERATING REQUIREMENTS 



The Utility function is implemented through execution of 
the programs in the module stored on the permanent file 
DCUTL. This file must be made available to the 
function. The Catalogue master files are also permanent 
files that must be made available to the function. In 
addition, certain facilities require other files. This 
section discusses the file requirements and operational 
considerations for using the Utility function. 

GENERAL CONSIDERATIONS 

The Utility function requires files that are used by all 
Data Catalogue functions. It also uses pseudo-switches 
that are common to all functions. 



PSEUDO-SWITCH SETTINGS 

Three of the four pseudo-switches used by Data Catalogue 
are applicable to the Utility function. These 
pseudo-switches, which indicate the function termination 
condition, are defined as follows: 

SW2 Set to ON for a normal termination of 

the function. 

5W3 Set to ON for a normal termination; 

however, an error occurred during 
processing. The Catalogue master files 
are not impaired, but the output should 
be carefully reviewed. 

SW4 Set to ON for an abnormal termination; 

a fatal error occurred during 
processing. The Catalogue master files 
were closed at the point the error was 
detected. The output should be 
reviewed to determine the nature of the 
error. It might be necessary to restore 
the files. 



COMMON FILES 

All facilities of the Utility function use the Catalogue 
master files. For card image input and printed output, the 
required files are the system files INPUT and OUTPUT, 
respectively. 

The Catalogue master files are three permanent files that 
contain all the information related to the Catalogue 
entries. These three files are referred to collectively as 
the Catalogue. Each new Catalogue that is initialized 
through the Utility function has its own copy of the 
master files. The three files are the data file (MASTl), 
the relational file (MAST2), and the control file (MAST3). 
Table 4-1 lists the file characteristics of the master files. 



FUNCTIONAL CONSIDERATIONS 

The Catalogue is initiated by the Utility function. This is 
the first function that is requested. After system 
initiation, the Utility function is requested to perform 
other support type operations. 



TABLE 4-1. CATALOGUE FILE CHARACTERISTICS 



Characteristic 


Data 
File 


Relational 
File 


Control 
File 


Logical file name 
(LFN) 


MASTl 


MAST2 


MAST3 


File organization 
(FO) 


Direct 
access 


Direct 
access 


Word ad- 
dressable 


Maximum block 
length (MBL) 


2550 


1270 


3840 


Maximimi record 
length (MRL) 


1265 


620 


3830 


Minimum record 
length (MNR) 


1265 


620 


3830 


Record type (RT) 


F 


F 


F 


Key length (KL) 


36 


36 


— 


Relative icey word 
(RKU) 








~ 


Relative key 
position (RKP) 








— 


Home blocks (HMB) 


User- 
definedt 


User- 
definedt 


— 


tBy data adninistr 


a tor. 







Input/output operations are performed by CYBER Record 
Manager (CRM). Error messages and file statistics are 
output by CRM to an error file when FILE control 
statements for the Catalogue files specify EFC=3. The 
CRMEP control statement is then used to print the 
messages and statistics. 



REQUIRED FILES 

The Utility function requires the modules on file DCUTL 
and the three Catalogue master files (MASTl, MAST2, and 
MAST3). It also requires the system file INPUT for input 
transactions and the system file OUTPUT for printed 
reports. 

Utility transactions are read from the system file INPUT. 
The first input transaction must be the $UTILITY 
statement. Other input transactions depend on the 
facility being requested. 

The files MASTl, MAST2, and MAST3 are created when 
the Utility initiation request is executed. For Utility 
maintenance requests, these files need only be attached. 
Examples of Utility requests are shown in section 5. 
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Backup and Restore Facilities 

Two or three additional files are required for the backup 
and restore facilities. If the BACKUP or RESTORE 
statement specifies DATA, only two files (MASTIBK and 
MAST2BK) are required for the data and relational files. 
If the statement specifies ALL, one additional file 
(MAST3BK) is required for the control file. Figure 4-1 
shows the file usage flow for the backup and restore 
facilities. Figures 4-2 and 4-3 show the control 
statements required to execute the backup and restore 
facilities, respectively. 

Before the restore facility is performed, the backup copy 
of the relational file (MAST2BK) should be sorted to 
obtain optimum consolidation of the file. The sort key 
begins in character position 1, is 36 characters in length, 
and is in display code. The sort is an ascending sort in the 
COBOL6 sequence. 

The files MASTIBK, MAST2BK, and MAST3BK are 
sequential files with C type blocks and F type records. 
The records are 620 characters in length. These files can 
reside on system internal formatted tapes or disk. 



Copy and Move Facilities 

The copy facility requires one additional file (TARGET) 
and the move facility requires two additional files 
(TARGET and SOURCE). The file TARGET contains the 
Update function transactions for updating the new 
(destination) Catalogue. The file SOURCE contains the 
Update function transactions for updating the existing 
(source) Catalogue. Figure 4-4 shows the file usage flow 
for the copy and move facilities. Figures 4-5 and 4-6 



NOS Operating System 

Job statement 

USER control statement 

CHARGE control statement 

ATTACH,DCUTL/UN=LIBRARY. 

ATTACH,MAST1,MAST2,IVIAST3/M=W,NA. 

FILE,MAST1,F0=DA,EFC=3. 

Fl LE.MAST2,FO=DA,EFC=3. 

Fl LE.MAST3,FO=WA,EFC=3. 

DEFI NE,MAST1 BK,MAST2BK,MAST3BK. 

DCUTL. 

CRMEP.LO. 



NOS/BE Operating System 

Job statement 

ATTACH,DCUTL. 

ATTACH,MAST1,ID=name. 

ATTACH,MAST2,I D=name. 

ATTACH,MAST3,I D=name. 

FILE,MAST1,FO=DA,EFC=3. 

Fl LE,MAST2,FO=DA,EFC=3. 

FILE,MAST3,FO=WA,EFC=3. 

REQUEST,MAST1BK,»PF. 

REaUEST,MAST2BK,*PF. 

REQUEST,MAST3BK,»PF. 

DCUTL. 

CATAL0G,MAST1BK,ID=name. 

CATALOG,MAST2BK.ID=name. 

CATAL0G,MAST3BK,I D^name. 

CRMEP.LO. 



Figure 4-2. Backup Facility Control Statements 



Input 
Trannctions 



MAST1 



MAST3 




MAST2 



I 



MAST3BK* 



MXVST2BK* 



*Can be a tape file. 



Figure 4-1. Backup and Restore Facilities File Usage 
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NOS Operating System 

Job statement 

USER control statement 

CHARGE control statement 

ATTACH,DCUTL/UN=LIBRARY. 

ATTACH,MAST1 ,MAST2.MAST3/M=W,NA. 

ATTACH,MAST1BK,MAST3BK/NA. 

ATTACH,STM2BK=MAST2BK/NA. 

FILE,MAST1,F0=DA,EFC=3. 

PI LE,MAST2,FO=DA,EFC=3. 

Fl LE,MAST3,FO=WA,EFC=3. 

Fl LE,STM2BK,BT=C,RT=F.FL=620. 

Fl LE,MAST2BK,BT=C,RT=F,FL=620. 

SORTMRG. 

DCUTL. 

CRMEP.LO. 



NOS/BE Operating System 

Job statement 

ATTACH,DCUTL. 

ATTACH,MAST1 ,1 D=name. 

ATTACH,MAST2,I D=name. 

ATTACH,MAST3,I D=name. 

ATTACH,MAST1BK,ID=name. 

ATTACH,STM2BK,M AST2B K.I D=name. 

ATTACH,MAST3B K,l D=name. 

Fl LE,MAST1.FO=DA,EFC=3. 

Fl LE,MAST2,F0=DA,E FC=3. 

Fl LE,MAST3,FO=WA,EFC=3. 

Fl LE,STM2BK,BT=C,RT=F,FL=620. 

Fl LE,MAST2BK,BT=C,RT=F,FL=620. 

SORTMRG. 

DCUTL. 

CRMEP,LO. 



IMPS Operating System 

Job statement 

USER control statement 

CHARGE control statement 

ATTACH,DCUTL/UN=LIBRARY. 

ATTACH,MAST1 .M AST2,MAST3. 

DCUTL. 

REWINDJARGET. 

COPYSBF,TARGET,OUTPUT. 



NOS/BE Operating System 

Job statement 
ATTACH.DCUTL. 
ATTACH,IVI AST1 ,1 D=name. 
ATTACH,MAST2,ID=name. 
ATTACH,IVI AST3,I D=name. 
DCUTL. 

REWINDJARGET. 
COPYSBFJARGET.OUTPUT. 



Figure 4-3. Restore Facility Control Statements 



Figure 4-5. Copy Facility Control Statements 

show the control statements required to execute the copy 
and move facilities respectively. 

The files TARGET and SOURCE are sequential files with 
C type blocks and Z type records. Both files can reside 
on system internal formatted tapes or disk. 

OPERATIONAL CONSIDERATIONS 

The minimum field length requirement for the Utility 
function is AOOOOg words. The programs that constitute 
the function are overlaid during processing. 



Input 
Transactions 



IVIAST1 





IVIAST2 



DCUTL 



MASTS 



*Can be a tape file. 





SOURCE* 



Utility 
Report 



Figure 4-4. Move and Copy Facilities File Usage 
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NOS Operating System 

Job statement 

USER control statement 

CHARGE control statement 

ATTACH,DCUTL/UN=LIBRARY. 

ATTACH.MASTI ,M AST2,MAST3. 

DCUTL. 

REWIND.SOURCEJARGET. 

COPYSBF,SOURCE,OUTPUT. 

COPYSBFJARGET.OUTPUT. 



NOS/BE Operating System 

Job statement 

ATTACH.DCUTL. 

ATTACH,M AST1 ,1 D=name. 

ATTACH,MAST2,I D=name. 

ATTACH,MAST3,I D=name. 

DCUTL. 

REWI ND^URCEJARGET. 

COPYSBF,SOU RCE,OUTPUT. 

COPYSBFJARGET.OUTPUT. 



Figure 4-6. Move Facility Control Statements 



Following the $UTILITV statement, the statements must 
be entered as described in previous sections of this 
manual. No sequencing by key fields is required- 

When the system is initiated, sufficient space should be 
allocated for MASTl and MAST2 to accommodate the 
expected maximum number of entries. Each block in 
MASTl and MAST2 can contain information related to two 
Catalogue entries. 

The Utility function has no run time options governing 
operational considerations. 



OUTPUT 

The Catalogue files are altered when the rename, 
renumber, copy, or move facility of the Utility function is 
used. The basic output of the function is the Data 
Administrator Utility Report. This report documents the 
facilities used. 

The backup facility produces the files MA5T1BK and 

MAST2BK; if requested, it also produces the file 

MAST3BK. The copy and move facilities produce the file 

TARGET; the move facility also produces the file 
SOURCE. 

The final output for a Utility request is as follows: 

»»»END DATA ADMINISTRATOR UTILITY REPORT*** 
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EXAMPLES 



Several examples are presented in this section to 
illustrate the use of the facilities available through the 
Utility function. Samples of input statements and output 
reports are shown for each facility. 

SYSTEM INITIATION 

The first function request that must be executed is a 
Utility request to initiate the system. This request 
identifies the installation and specifies the space 
requirements for the Catalogue. Optional features can be 
selected in a request for initiation. 

Figure 5-1 illustrates the control statements and the input 
statements for a Utility request for initiation. The 
module DCUTL must be attached. The three Catalogue 
master files (MASTl, MAST2, and MAST3) must be 
established as permanent files; MASTl and MAST2 are 
direct access files and MAST3 is a word addressable file. 
The input statements included in this request provide the 
installation name and address, the number of home blocks 
for MASTl and MAST2, the number of lines per page, and 
an end-of-page message. 

The Data Administrator Utility Report output for the 
request shown in figure 5-1 is illustrated in figure 5-2. 
This report indicates the input statements and the results 
of executing the statements. 



SYSTEM MAINTENANCE 

Once the system has been initiated, the Utility function is 
used to maintain the system. Facilities are provided to 
backup and restore the Catalogue, copy and move entries 
from one Catalogue to another, rename entries, renumber 
lines, and display statistics. 



BACKUP FACILITY 

Figure 5-3 illustrates the control statements and the input 
statements for a Utility request to backup the Catalogue 
master files. The three Catalogue files (MASTl, MAST2, 
and MAST3) and the module DCUTL must be attached. 
The files to be used for the backup files (MASTIBK, 
MAST2BK, and MAST3BK) must be established as 
permanent files. The BACKUP statement in this request 
specifies ALL, which means that all three Catalogue files 
are to be processed. 

The Data Administrator Utility Report shown in 
figure 5-4 lists the statements in the request and then 
indicates the number of entries for each entity type. The 



last three lines of the report indicate the totals for each 
of the three Catalogue files. 



RESTORE FACILITY 

Figure 5-5 illustrates the control statements and input 
statements for a Utility request to restore the Catalogue 
files. The three Catalogue files (MASTl, MAST2, and 
MAST3), the module DCUTL, and the three backup files 
(MASTIBK, MAST2BK, and MAST3BK) must be attached. 
The RESTORE statement in this request specifies ALL to 
restore the three Catalogue files. 

The Data Administrator Utility Report generated by the 
request in figure 5-5 is shown in figure 5-6. The input 
statements are shown followed by a listing of the number 
of entries restored for each entity type. The last three 
lines of the report indicate the totals for each of the 
three Catalogue files. 



MOVE FACILITY 

The control statements and input statements for a Utility 
request to move entries from one Catalogue to another 
are illustrated in figure 5-7. The three Catalogue files 
(MASTl, MAST2, and MAST3) and the module DCUTL 
must be attached. The MOVE statement in this request 
specifies that the entry with the Catalogue name 
INVENTORY and all entries within its hierarchy are to be 
moved to the destination Catalogue; a listing of the 
entries is also specified in the statement. 

Figure 5-8 shows the Data Administrator Utility Report 
produced by the request in figure 5-7. This report lists 
the request statements and then the number of 
transactions written to the files TARGET and SOURCE. 
This is followed by a listing of the card images on both 
files. 



DISPLAY FACILITY 

Figure 5-9 illustrates the control statements and input 
statements for a Utility request to display statistics. The 
Catalogue control file (MAST3) and the module DCUTL 
must be attached. The DISPLAY statement requests the 
current number of lines per page. 

The Data Administrator Utility Report shown in 
figure 5-10 lists the input statements and then indicates 
that 50 lines are printed on a page. 
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NOS Operating Systern 



Job statement. 

USER control statement. 

CHARGE control statement. 

i»tTiMJM,OCUIt/0N=«LIBRARY. 

PUR<% f MAST 1, MAST 2» MAST 3/NA. 

R£TURNtHASTi*MAST2,NAST3. 

0EFINE»NAST1>MAST2*MAST3. 

FILE, MASTl ,FO*OA ,£FG«3. 

FXLE>MAST2»F0=0A|EFC':3. 

FILP»MAST3iF0-UA,EFCs3. 

OCUTL. 

CRMEP*LO. 

EXIT. 

OHP. 

0MP,377777. 

CRI«P*LO. 

7/S/9 card 



NOS/BE Operating System 



Job statement. 

ATTACH, OCUTL. 

lieOHIEST» MASTl, PF. 

RE9UEST,MAST2,PF. 

»EeM«ST»MAST3*PF. 

FILE,NASTl,Fl»«DA,EFCa3, 

FltE»M«ST2,rO=OA.EFC»3. 

riLE.MA«5r5,F0«MA,€FC*3, 

OCUTL. 

CATAt05»MASTl,ld«0C2»Ptl»DC!?,RP«999. 

CATALOG tMAST2,10«DC2tP«*OC2,RP» 999. 

CATALOG ,MAST3,T0«0C2.PH«0C2,»P»9<»9, 

CRMEPvLfl. 

C«IT. 

9MP. 

0MP,37rrrii. 

CRMEPeLO. 
7/B/9 card 



tutZLnv in 

NAHE THE DATA CATALOGUE MANUAL 

MO 08A ROOM 

MNa«211 

UN 90 

EN0MS6 MANUAL END OP PACE 

6/VV9 card 



Figure 5-1. Initiation Request Example 



CATA CATALOGUE 2 
CAT A ADMINISTRATOR UTILITY REPORT 



«tTILITY 1»I 

NAME THE CATA CATALOGL£ MANUAL 

IfOC OBA RQCM 

OATA CATAwCGUE FILES HAME 9££M INITIATEC 
tijtAUAtlCKt THE DATA CATALOGUE M»iLAL 
iCORESS* OEA (ROOM 
OATE* 06/0 S/ 79 
HCNE SLOCK » 211 



CAT A ADMINISTRATOR UTILITY REPORT 
LIN 90 
LI^ES PER PAGE M.TEREO FROP 99 TO SO 



0*1A ADMINISTRATOR UTILITY REPORT 



EM0IS6 NANUAL END OF PAGE 

END OP PAGE MESSAGE ALTERED 
FRON^ 
T0» NANUAL END OF PAGE 



*** END OF DATA ADMINISTRATOR UTILITY REPORT 



Figure 5-2. Report for Initiation Request 
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NOS Operatinfl System 




NOS/BE -Operating System 


Job statement. 




Job statement. 


USER control statement. 




ATTRCH.BCUTt. 


CHARGE control statement. 




ATrACH, HASTl, T0=0C2 »«»W=0C2. 


*TT»CH,OCtTL/UN=lIBR*RY. 




ATTACH, MftST2,IDxOC2,PH»DC2. 


ATTACH, H*ST1,MAST2,M/1ST3/M = M,N«. 




ATr ACHtHASr 3, 10^002, PM=DC2. 


FILE ,HAST1,F0»DA,EFC=3. 




FlLE,NASrt,F-0»DA,EFC«3. 


FILE,HAST2,F0>:D«,EFCs3. 




FILE,MAST2,F3=OA,EFC=3. 


FILE. MAST 2,F0=Hfl,EFC=3. 




FILE,HAST3, F3»MA,EFC« 3, 


PURCE,nASTieK,MAST2eK,KAST3eK/NA. 




REaaEST,MAST19K,f»F, 


RETURN, HAST 18K, M AS TZEK, HAS T3BK. 




RE(MIEST,HAST2aK,PF. 


EEFI»E,>*AST18K,HAST2GKtHAST3BK. 




REQ8EST,»1AST3BK»PF, 


DCUTl. 




DCUTL. 


CRKEF.LC. 




CATALOG, MAST1BK,IO»!OC2,PH«OCZ,«P« 9^9. 


EXIT. 




CAT»L35,MAST2BK,I0=0C2,PM=0C2,RP'!999. 


CMP. 




CATAL0S,HAST3B«;,IO=OC2,PW=OC2,«>P=999. 


CHF,J7777?. 




CRHEPftO. 


CRMEP*10. 




EKIT. 


7/8/9 card 


JUTIllTV 
EACKUP ALL 

6/7/8/9 card 


BM". 

BMP, 377777. 

CRMEP,LO. 

7/8/9 card 



Figure 5-3. Backup Request Example 



DATA CATALOGUE 


2 










THE CATA CATALOGUE NANUAL 


















DATA 


C A T A L ; U 


E 2 










DATA AOHINISTRATOR UTILITY 


REPORT 


SUTIIITV 




















DATA ADMINISTRATOR UTILITY 


REPORT 


BACKLP 


ALL 












NE KAVE SACKED UPl 










12 


RECORDS 


REPRESENTING 


12 


ELEMENT 


ENTRIES 







RECORDS 


REPRESEMING 





GROUP 


ENTRIES 




3 


RECORDS 


REPRESEHTING 


2 


RECORD . 


ENTRIES 







RECORDS 


REPRESEKTING 





DATA SET 


ENTRIES 




1 


RECORDS 


REPRESENTING 


1 


FILE 


ENTRIES 







RECORDS 


REPRESENTING 





TOTAL 


ENTRIES 




1 


RECORDS 


REPRESEKTING 


1 


FORH 


ENTRIES 




2 


RECORDS 


REPRESENTING 


2 


REPORT 


ENTRIES 







RECORDS 


REPRESEKTING 


a 


EXTERNAL 


ENTRIES 




8 


RECORDS 


REPRESENTING 


8 


HOCULE 


ENTRIES 




a 


RECORDS 


REPRESEKTING 





TASK 


EMTRIES 




1 


RECORDS 


REPRESEKTING 


I 


SrSTEM 


ENTRIES 







RECORDS 


REPRESENTING 





USERS 


ENTRIES 




26 


RECORDS 


REPRESENTING 


27 


TOTAL 


ENTRIES 




29 


RECORDS 


REPRESEKTING 


28 


REFERENCE 


ENTRIES 




71 


RECORDS 


REPRESENTING 


71 


CONTROL 


ENTRIES 








«•« 


END 


OF DATA ADHINISTRATJR UTILITY REPORT ••• 



Figure 5-4. Report for Backup Request 
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NOS Operating System 










NOS/BE Operating System 




Job statement. 










Job statement. 




USER control statement. 










ATTACH, OCUTL. 




CHARGE control statement. 










ATTACH. HAST1»ID=OC2.PM«OC2. 




ATTACH,OCUTL/UN-LIBRAftY. 








ATTACH* HAST?, IDsOC2.PMsOC2. 




ATTACH, HASTl,MAST2,MAST3/MaH,NA. 








ATTACH, HAST3, IO=0C2,PHcOC2. 




ATTACH,MAST13K,MA3T3BK/HA. 








ATTACH,HAST19<,ID=0C2,PM=nC2. 




ATTACH,STH26K=MAST28K/NA. 








ATTACH, STH2BK,HAST2BK, 10= DC2,PMs 


0C2. 


FILE 1 HASTl ,FO=OA,eFC= 


= 3. 








ATTACHvNASTSqK, 10=002 ,PH=OC?. 




FILE,HAST2,F0=0A,£FC= 


= 3. 








FILEtNASTl ,F0«DA,EFCs3. 




FILE,HAST3,F0=HA,EFC=3. 








FILE«HAST2,F0=OA,EFC«3, 




FIL£,STM23K,aT=C,RT=F ,FL=620. 








F1LE,HASTS.F3«MA,EFC«3, 




FIL£,HASt2eK>6T-C»RTsr,Ft.s62a. 








FILE.STH2BK,3T=C,RT=F,FL=628. 




SORTHRG. 










ILE*HAST2BK,BTsC,RT«F,FLs62a. 




dCUTt . 










.SORTNRC. 




CRHCP^LO. 










oeuTL. 




EXIT. 










CRHEP,LO. 




OMp. 










EtIT. 




OMI», 377777. 










oiiP. 




CRM£P,LO. 










OUP.STTrt?. 




7/8/9 card 










eiuilFP,Lo. 






SORT 








7/8/9 card 






FILE* INPUT sSTtf26f(( CI 


.OU^UTsNASTZeKIRI 






riE4.0»NAIi|£ll, 


36i 


DISPLAY ) 








NEy«NAnEfA«coeoi.«> 










EMC 














7/S/0 card 














iufkity 

RESTORE AtL 

6/7/8/9 card 













Figure 5-5. Restore Retiueat Exannple 
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DATA CATALOGUE Z 

THE DATA CATALOGUE MANUAL 



tUTILITV 



DATA CATALOGUE 2 
DATA AOKINISTRATOR UTILITY REPORT 



OATA ACMINISTRATCR UTILITY REPORT 



RESTORE ALL 



WE HAVE RESTORED! 



tZ RECORDS 
RECORDS 
RECORDS 
RECCROS 
RECORDS 
RECORDS 
RECORDS 
RECORDS 
RECORDS 
RECCROS 
RECORDS 
RECCROS 
RECORDS 

28 RECORDS 

29 RECCROS 
123 RECCROS 



3 

a 
1 



I 

2 

6 

1 




REPRESENTING 
REPRESENT! KG 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 
REPRESENTING 



12 


ELEMENT 


ENTRIES 


fl 


GRCUP 


ENTRIES 


2 


fiECCfiO 


ENTRIES 





CATASET 


ENTRIES 


1 


FILE 


ENTRIES 





TOTAL 


ENTRIES 


1 


FCRH 


ENTRIES 


2 


REPORT 


ENTRIES 





EXTERNAL 


ENTRIES 


3 


KCCULE 


ENTRIES 





TASK 


ENTRIES 


1 


SYSTEH 


ElftRIES 





LSERS 


ENTRIES 


27 


TOTAL 


ENTRIES 


28 


REFERENCE 


ENTRIES 


1*3 


REFERENCE 


ENTRIES 



•♦♦END CF DATA ADMINISTRATOR UTILIT* REPORT •♦• 



Figure 5-6. Report for Restore Request 



NOS Operating System 




NOS/BE Operating System 


Job statement. 




Job statement. 


USER control statement. 


_. 


ATTACHtOCUTL. 


CHARGE control statement. 




ATTACH, MASTltinsOCZ ,PW=0C2. 


ATTACH, DCUTL/UN=LItiRARY. 




ATTaCH.NAST3,lO=DC2,PW=nC2. 


ATTACH,HAST1,MAST2,MAST3. 




ATrACH,HASr3,T0=0C2,PM=DC''. 


CCUTU . 




OCUTL. 


RENIND, SOURCE, TARGET. 




REHTMD,SOU!?CP, TARGET. 


COP YSSF, SOURCE, OUTPUT. 




COPYSBf.SOUUCE.OUToUT. 


COPYS BF , TA RGtT , OUTPUT . 




COPYS'^F,T«e.GET-, CUTOUT. 


CRHEP.LO. 




CRMEP.LO, 


EXIT. 




Elflt. 


ONP. 




B«». 


OMP, 377777. 




9WP, 377777. 


CRMEP.LO. 




CRMPP.LO. 


7/8/9 card 




7/8/9 card 


tUTIHTY 




MOtfE 


Hli. = iNtfcNTORY, 


LlSTsYES 


6/7/8/9 card 





Figure 5-7. Move Request Example 
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OAT* CATALC6UE 2 " 

THE DATA CATALQGUE MANUAL 

DATA GATALOGUEZ 

DATA ADHINISTRATOft UTILITY REPORT 

tUTJLITY 

DATA ADMINISTRATOR UTILITY REPORT 
MOVE HIE»lNtfENTORY,LIST«YES 

3*1 TRANSACTIONS WERE WRITTEN TO TARGET FILE 
17 TRANSACTIONS HERE MfilTTE^ TO SOURCE FILE 

OAT A ADMINISTRATOR UTILITY REPORT 

1 2 3 *» 5 7 6 

TARGET CARD IMAGE 1 0... 0........*0 ....0 ))...0..3 

$UPO«TE 

OPTIONS REV-N0=N0-CHt<,E01T-0NLY=NO 

ADO fIl=IKVENTORV 

ADO REC»PART-iaC 

ADO ELE=PART-NO 

ADO ELE»NC-PART 

AOO ELE=eACK-OROER 

ADD ELEsON-CROER 

ADD ELE=REOROER-PT 

AOO CLEsLEAO-TIME 

AOO ELE=U«T-MEICHT 

AOO £L£3UKIT-C0ST 

AOO ELE=UMT-PRICE 

ADD ELE=0ESCRIPTION 

AOO ELEsCHECKSUM 

ADD REC=PfiOFIT-REC 

AOO ELE=PART-NO 

AOO a.E=U KIT-COST 

ADD ELE=UMT-PR1CE 

CHG FIL=IhVENTCRY 

CON 

0001 EST=e 

GLA 

0001 KtV=CLASS=PART,PARTS,INWENTORY, STOCK 

OES 

0001 THIS FILE HAS ALL INFORMATION ABOUT PARTS 

R€S 

0001 STA=P,FUN*C.OEP=INVENTORY OEPT, 

PtRst-R. PART FIRST 
0005 PHC=73«i 7J»39,TIT=MGR,HAIsSVtlO,OATal01078 
0010 STA=C»C£PsINVtNTORV OEPTfFER=KR. PART SECOND 
0015 PHC=73i.7 7600iTIT = HGRiMAIsSV10«»tOAT=i22578 



Figure 5-B. Report for Move Request (Sheet 1 of 2) 
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CATA 


ADMINISTRATOR UTILITY 


■ REPORT 











1 2 


3 


<» 


5 




7 


a 


SOURCE CARD IMAGE !•••< 


■••••0«>a««.«««Oi 


........0....... 
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, ,.0... . 
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.. 0..3., 


• • • • Q 


V ^^ ^^ IX ^^ ^K 1^ ^ tX ^ A * > r^ \^ h» ^ V V V 

DEL 


fILsIKWEHTORY 






MHE REUSED 


•*{(•*" 






DEL 


REC=PART-REC 






MHEREUSEO 








OEL 


EL£=PART-NO 






MHEREUSEO 








DEL 


ELE=NC-PART 






WHEREUSEO 








OEL 


ELEsEACK-OROtR 






MHEREUSEO 








DEL 


ELE=C^-CROER 






MHEREUSEO 








OEL 


EL£=REORDER-PT 






MHEREUSEO 








OEL 


atsLEAC-TIHE 






MHEREUSEO 








OEL 


ELt=U«T-HEIGHT 






MHEREUScO 








OEL 


ELE=UMT-COST 






MHEREUSEO 








OEL 


ELE=UMT-PRICE 






MHEREUSEO 








OEL 


ELE»OESCRIPTION 






MHEREUSEO 








OEL 


EL£=CHECKSUM 






MHEREUSEO 








OEL 


REC=PPOFIT-REC 






MHEREUSEO 








OEL 


£LE=PART-NO 






MHEREUSEO 








OEL 


£LE=UMT-COST 






MHEREUSEO 








OEL 


ELE=LMT-PR1CE 






MHEREUSEO 








♦•• EKO OF DATA ADMINISTRATOR UTILITY 


REPORT ••• 









Figure 5-8. Report for Move Request (Sheet 2 of 2) 



NOS Operating System 






NOS/BE Operating System 


Job statement. 
USER control statement. 
CHARGE control statement. 
ATTACH, OC»TL^UN=LIBRARY,N«. 
ATTACH,MAST3, 
OCUTL. 
. EXIT. 
DNP. 

ONP, srrrrr, 

7/8/9 canJ 






Job statement. 

ATTACH, OCUTL. 

ATT ACH, WRST3, I0s0C2,»»H=0C2. 

OCUTL. 

EXIT. 

oifp,3rrrrr. 

7/8/9 card 




fUTTLirv 

DTS LtM 

6/7/8/9 card 





Figure 5-9. Display Request Example 
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DATA CATA10GU£ Z 
THE DATA CATALOGUE 


MANUAL 






A 


T A 


C A t A 


L 


6 U 


E 


2 














DATA 


ADMINISTRATOR 
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STANDARD CHARACTER SETS 



Control Data operating systems offer the following 
variations of a basic character set: 

CDC 64-character set 

CDC 63-character set 

ASCII 64-character set 

ASCII 63-character set 

The set in use at a particular installation is specified when 
the operating system is installed. 

Depending on another installation option, the system 
assumes an input deck has been punched either in 026 or in 
029 mode (regardless of the character set in use). 

Under NOS/BE, the alternate mode can be specified by a 
26 or 29 punched in columns 79 and 80 of the job 



statement or any 7/8/9 card. The specified mode remains 
in effect throughout the job unless it is reset by 
specification of the alternate mode on a subsequent 7/8/9 
card. 



Under NOS, the alternate mode can be specified by a 26 
or 29 punched in columns 79 and 80 of any 6/7/9 card, as 
described above for a 7/8/9 card. In addition, 026 mode 
can be specified by a card with 5/7/9 multipunched in 
column 1; 029 mode can be specified by a card with 5/7/9 
nniltipunched in column 1 and a 9 punched in column 2. 



Graphic character representation appearing at a terminal 
or printer depends on the installation character set and 
the terminal type. Characters shown in the CDC Graphic 
column of the standard character set table are applicable 
to BCD terminals; ASCII graphic characters are applicable 
to ASCII-CRT and ASCH-TTY terminals. 
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TABLE A-1. STANDARD CHARACTER SETS 



Display 
Code 
(octal) 


CDC 


ASCII 1 


Graphic 


Hollerith 
Punch 
(026) 


External 
BCD 
Code 


Graphic 
Subset 


Punch 
(029) 


Code 
(octal) 


00+ 


: (colon)'^^ 


8-2 


00 


: (colon) ++ 


82 


072 


01 


A 


12-1 


61 


A 


12-1 


101 


02 


B 


12-2 


62 


B 


12-2 


102 


03 


C 


12-3 


63 


C 


12-3 


103 


04 


D 


12-4 


64 


D 


12-4 


104 


OS 


E 


12-5 


65 


E 


12-5 


105 


06 


F 


12-6 


66 


F 


12-6 


106 


07 


G 


12-7 


67 


G 


12-7 


107 


10 


H 


12-8 


70 


H 


12-8 


110 


11 


1 


12-9 


71 


1 


12-9 


111 


12 


J 


11-1 


41 


J 


11-1 


112 


13 


K 


11-2 


42 


K 


11-2 


113 


14 


L 


11-3 


43 


L 


11-3 


114 


15 


M 


11-4 


44 


M 


11-4 


115 


16 


N 


11-5 


45 


N 


11-6 


116 


17 





11-6 


46 





11-6 


117 


20 


P 


11-7 


47 


P 


11-7 


120 


21 


Q 


11-8 


50 


Q 


11-8 


121 


22 


R 


11-8 


51 


R 


11-9 


122 


23 


S 


fr2 


22 


S 


0-2 


123 


24 


T 


03 


23 


T 


0-3 


124 


25 


U 


0-4 


24 


U 


0-4 


125 


26 


V 


0-5 


25 


V 


0-6 


126 


27 


w 


0-6 


26 


w 


0« 


127 


30 


X 


0-7 


27 


X 


0-7 


130 


31 


Y 


0-8 


30 


Y 


0-8 


131 


32 


z 


0-9 


31 


z 


08 


132 


33 








12 








060 


34 


1 


1 


01 


1 


1 


061 


35 


2 


2 


02 


2 


2 


062 


36 


3 


3 


03 


3 


3 


063 


37 


4 


4 


04 


4 


4 


064 


40 


5 


5 


05 


5 


5 


065 


41 


6 


6 


06 


6 


6 


066 


42 


7 


7 


07 


7 


7 


067 


43 


8 


8 


10 


8 


8 


070 


44 


9 


9 


11 


9 


9 


071 


45 


+ 


12 


60 


■I- 


12-8-6 


053 


46 


* 


11 


40 


* 


11 


055 


47 


11-8-4 


54 


11-8-4 


052 


50 


1 


0-1 


21 


/ 


0-1 


057 


51 


{ 


0-8-4 


34 


{ 


12-8-5 


050 


52 


) 


12-8-4 


74 


) 


11-8-5 


051 


53 


$ 


11-8-3 


53 


$ 


11-8-3 


044 


54 


= 


8-3 


13 




8-6 


075 


55 


blank 


no punch 


20 


blank 


no punch 


040 


56 


, (comma) 


0-8-3 


33 


, (comma) 


0-8-3 


054 


57 


. (period) 


12-8-3 


73 


. (period) 


12-8-3 


056 


60 


= 


0-8-6 


36 


# 


8-3 


043 


61 


[ 


8-7 


17 


C 


12-8-2 


133 


62 


1,, 


0-8-2 


32 


3,, 


11-8-2 


135 


63 


%tt 


8-6 


16 


%+t 


08-4 


045 


64 


3^ 


8-4 


14 


" (quote) 


8-7 


042 


65 


r* 


0-8-5 


35 


(underline) 


08-5 .^^ 


137 


66 


V 


11-0 or 11-8-21++ 


52 


1 


12-8-7 or 11-0+++ 


041 


67 


A 


0-8-7 


37 


8t 


12 


046 


70 


t 


11-8-5 


55 


' (apostrophe) 


8-5 


047 


71 


J 


11-8-6 ^^^ 


56 


? 


0-8-7 ... 


077 


72 


< 


12-0 or 12-8-2+++ 


72 


< 


12-8-4 or 120+++ 


074 


73 


> 


11-8-7 


57 


> 


08-6 


076 


74 


< 


8-5 


15 


@ 


8-4 


100 


75 


> 


12-8-5 


75 


\ 


0-8-2 


134 


76 


-1 


12-8-6 


76 


- (circumflex) 


11-8-7 


136 


77 


; (semicolon) 


12-8-7 77 1 


; (semicolon) 


11-8-6 


073 


Twelve zero bits at the end of a 60-bit word in a zero b^ 


rte record are an er 


id of record mark rather than 


two colons. 
"^'In installations using a 63-graphic set, display code 00 h 






as no associated gr 


aphic or card code; display 


code 63 is the colon (8-2 punch). The % graphic and 


related card codes 


do not exist and translations 


yield a blank (55g). 
'^^TThe alternate Hollerith (026) and ASCII (029) punches 






are accepted for in 


put only. 
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TABLE A-2. CDC CHARACTER SET COLLATING SEQUENCE 



Collating 








Collating 








Sequence 


CDC 


Display 


External 


Sequence 


CDC 


Display 


External 


Decimal/Octal 


Graphic 


Code 


BCD 


Decimal/Octal 


Graphic 


Code 


BCD 


00 00 


blank 


55 


20 


32 40 


H 


10 


70 


01 01 


< 


74 


15 


33 41 


1 


11 


71 


02 02 


% 


63t 


16t 


34 42 


V 


66 


52 


03 03 


[ 


61 


17 


35 43 


J 


12 


41 


04 04 


— 


65 


35 


36 44 


K 


13 


42 


05 05 


= 


60 


36 


37 45 


L 


14 


43 


06 06 


A 


67 


37 


38 46 


M 


15 


44 


07 07 


t 


70 


55 


39 47 


N 


16 


45 


08 10 


i 


71 


56 


40 50 





17 


46 


09 11 


> 


73' 


57 


41 51 


P 


20 


47 


10 12 


> 


75 


75 


42 52 


Q 


21 


50 


11 13 


— , 


76 


76 


43 53 


R 


22 


51 


12 14 


. 


57 


73 


44 54 


] 


62 


32 


13 15 


) 


52 


74 


45 55 


S 


23 


22 


14 16 


1 


77 


77 


46 56 


T 


24 


23 


15 17 


+ 


45 


60 


47 57 


U 


25 


24 


16 20 


$ 


53 


53 


48 60 


V 


26 


25 


17 21 


* 


47 


54 


49 61 


w 


27 


26 


18 22 


- 


46 


40 


50 62 


X 


30 


27 


19 23 


/ 


50 


21 


51 63 


Y 


31 


30 


20 24 


/ 


56 


33 


52 64 


z 


32 


31 


21 25 


( 


51 


34 


53 65 




00 t 


nonet 


22 26 


= 


54 


13 


54 66 





33 


12 


23 27 


# 


64 


14 


55 67 


1 


34 


01 


24 30 


< 


72 


72 


56 70 


2 


35 


02 


25 31 


A 


01 


61 


57 71 


3 


36 


03 


26 32 


B 


02 


62 


58 72 


4 


37 


04 


27 33 


C 


03 


63 


59 73 


5 


40 


05 


28 34 


D 


04 


64 


60 74 


6 


41 


06 


29 35 


E 


05 


65 


61 75 


7 


42 


07 


30 36 


F 


06 


66 


62 76 


8 


43 


10 


31 37 


G 


07 


67 


63 77 


9 


44 


11 


tin installations using the 63-c 


iraphic set. 


tine % graph 


does not exist. 


The : graph 


c is display 


code 63. 


External BCD code 16. 
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TABLE A-3. ASCII CHARACTER SET COLLATING SEQUENCE 



Collating 


ASCII 






Collating 


ASCII 






Sequence 
Decimal/Octal 


Graphic 
Subset 


Display 
Code 


ASCII 
Code 


Sequence 
Decimal/Octal 


Graphic 
Subset 


Display 
Code 


ASCII 
Code 


00 00 


blank 


55 


20 


32 40 


@ 


74 


40 


01 01 


! 


66 


21 


33 41 


A 


01 


41 


02 02 


// 


64 


22 


34 42 


B 


02 


42 


03 03 


# 


60 


23 


35 43 


C 


03 


43 


04 04 


$ 


53 


24 


36 44 


D 


04 


44 


05 05 


% 


63t 


25 


37 45 


E 


05 


45 


06 06 


& 


67 


26 


38 46 


F 


06 


46 


07 07 


t 


70 


27 


39 47 


G 


07 


47 


08 10 


( 


51 


28 


40 50 


H 


10 


48 


09 11 


) 


52 


29 


41 51 


! 


11 


49 


10 12 


* 


47 


2A 


42 52 


J 


12 


4A 


11 13 


+ 


45 


2B 


43 53 


K 


13 


4B 


12 14 




56 


2C 


44 54 


L 


14 


4C 


13 15 


- 


46 


2D 


45 55 


M 


15 


4D 


14 16 




57 


2E 


46 56 


N 


16 


4E 


15 17 


/ 


50 


2F 


47 57 





17 


4F 


16 20 





33 


30 


48 60 


P 


20 


50 


17 21 


1 


34 


31 


49 61 


Q 


21 


51 


18 22 


2 


35 


32 


50 62 


R 


22 


52 


19 23 


3 


36 


33 


51 63 


S 


23 


53 


20 24 


4 


37 


34 


52 64 


T 


24 


54 


21 25 


5 


40 


35 


53 65 


U 


25 


55 


22 26 


6 


41 


36 


54 66 


V 


26 


56 


23 27 


7 


42 


37 


55 67 


w 


27 


57 


24 30 


8 


43 


38 


56 70 


X 


30 


58 


25 31 


9 


44 


39 


57 71 


Y 


31 


59 


26 32 




oot 


3A 


58 72 


z 


32 


5A 


27 33 


; 


77 


3B 


59 73 


[ 


61 


58 


28 34 


< 


72 


3C 


60 74 


\ 


75 


5C 


29 35 


= 


54 


3D 


61 75 


] 


62 


5D 


30 36 


> 


73 


3E 


62 76 




76 


5E 


31 37 


? 


71 


3F 


63 77 


- 


65 


5F 


fin installations using a 


33 -graphic 


set, the % graphic does 


not exist. 


rhe : graph 


ic is 


display code 63. 
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ERROR PROCESSING AND DIAGNOSTICS 



B 



Diagnostics issued by the Utility function are usually 
associated with input transactions and are listed on the 
Data Administrator Utility Report. Two types of 
diagnostics can be issued: 



Fatal 



The Utility function cannot be initiated or it has 
terminated prematurely. Fatal errors are usually 
caused by the absence of a required statement, 
which is corrected by entering the appropriate 
statement. Fatal errors can also occur if the 
Catalogue master files have been impaired. This 
type of error usually necessitates restoration of 
previously backed up files. A fatal error is 
always indicated by the ON condition for 
pseudo-switch 4 (SWA). 



Serious 



A particular transaction cannot be processed. 
For example, an invalid l<ey word has been 
encountered. The next transaction is read and 
normal processing continues. A serious error is 



always indicated by the 
pseudo-switch 3 (SW3). 



ON condition for 



Data Catalogue diagnostics are output in the following 
message format: 

function-number-severity »ERROR message text 

The first part of the message identifies the function being 
requested, the unique error number for that function, and 
the severity of the error. The function identifier for the 
Utility function is DCUTL. The severity level is indicated 
by the letter F (fatal) or S (serious). The following 
example of the first part of an error message indicates 
serious error number 410 diagnosed by the Utility function: 

DCUTL-410-S 

Table B-1 . lists the diagnostics issued by the Utility 
function. The table shows in tabular format the error 
number, severity level, and message text output by the 
function. Two additional columns in the table indicate the 
significance of the error and the action to be tal<en to 
correct the error. 



TABLE B-1. UTILITY FUNCTION (DCUTL) DIAGNOSTICS 



Error 
Number 


Severity 


Message 


Significance 


Action 


400 


S 


SUTILITY TRANSACTION 


The first statement is not the 
$UTILITY statement, or it did not 
specify one of the following: 

INI 

INITIATE 

MAI 

MAINTENANCE 

space 


Correct and enter the 
$UTILITY statement. 


405 


S 


OPERAND MUST BE DAT OR 
ALL 


The phrase in the BACKUP or 
RESTORE statement is invalid. 


Correct the statement 
to specify DAT, DATA, 
or ALL. 


410 


S 


KEYWORD INVALID 


The input statement is invalid. 


Correct the statement. 


800 


S 


MASTl WRITE catname 


Invalid key path taken. 


For a restore opera- 
tion, ensure that 
Initialization has 
been performed. For 
any other operation, 
the Catalogue has 
been damaged; restore 
a backup copy of the 
Catalogue. 
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TABLE B-1. UTILITY FUNCTION (DCUTL) DIAGNOSTICS (Contd) 



Error 
Number 


Severity 


Message 


Significance 


Action 


805 


S 


MAST2 WRITE catname 


Invalid key path taken. 


For a restore opera- 
tion, ensure that 
initialization has 
been performed. For 
any other operation, 
the Catalogue has 
been damaged; restore 
a backup copy of the 
Catalogue. 


810 


S 


MASTl READ catname 


Invalid key path taken. 


Restore a backup copy 
of the Catalogue. 


815 


S 


MAST2 READ catname 


Invalid key path taken. 


Restore a backup copy 
of the Catalogue. 


900 




NAME TRANSACTION MUST BE 
SPECIFIED 


The Utility initiation request 
does not include the NAME state- 
ment. 


Enter the NAME state- 
ment. 


905 




ADDRESS TRANSACTION MUST 
BE SPECIFIED 


The Utility initiation request 
does not include the ADDRESS 
statement. 


Enter the ADDRESS 
statement. 


915 




HMB MUST BE NUMERIC 


The HMB statement does not 
specify a numeric value. 


Correct the HMB 
statement. 


950 




MAST3-UNABLE TO LOCATE 
CUST RECORD 


A problem has been encountered 
with the control file (MAST3) in 
the Catalogue. 


Reload the backup 
copy of the Catalogue. 


960 




MAST3-UNABLE TO LOCATE 
ENTRY RECORD 


A problem has been encountered 
with the control file (MAST3) in 
the Catalogue. 


Reload the backup 
copy of the Catalogue. 


965 




MAST3-UNABLE TO LOCATE 
CATS RECORD 


A problem has been encountered 
with the control file (MAST3) in 
the Catalogue. 


Reload the backup 
copy of the Catalogue. 


970 




MASTS-UNABLE TO LOCATE 
FIELD RECORD 


A problem has been encountered 
with the control file (MAST3) in 
the Catalogue. 


Reload the backup copy 
of the Catalogue. 


995 




INITIATION INCOMPLETE 


This message accompanies any of 
the messages numbered 900 through 
970. 


Rerun the initializa- 
tion request. 
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GLOSSARY 



Alias - 

An element, group, or record entry that is established 
as a variation of another entry in the Catalogue. A 
category of information in an element entity used to 
document alternate names and descriptions for an 
element. 

Catalogue - 

A computerized dictionary of data, procedures, and 
users; the master files that contain all the 
information related to the entity definitions. The 
Catalogue consists of a data file, a relational file, 
and a control file. It is a central repository where 
information processing documentation can be 
maintained, accessed, retrieved, and distributed at 
computer speeds. 

Catalogue Name - 

The unique key that identifies and relates all of the 
information concerning an. entry in the Catalogue. 
Each entry must be assigned a unique Catalogue name. 

Category - 

A class of information that is used to define an entity 
to Data Catalogue. Several categories exist and are 
used in various combinations to define different 
entity types. A category contains one or more fields 
of information. 

Convert Function - 

The Data Catalogue procedure used to create entity 
definitions from existing COBOL programs and 
TOTAL DBDLs. Input transactions are generated by 
the Convert function for processing by the Update 
function. 

Data Base Entity - 

A collection of information that describes the 
characteristics of a TOTAL data base. A data base is 
a logical aggregate of data; it is the collection of 
datasets that participate in a defined relationship. 

Data Dictionary - 

Synonymous with Catalogue. 

Data Entities - 

A class of entity types for defining data structures. 
Element, group, record, file, dataset, and data base 
entity types are data entities. 

Dataset Entity - 

The entity type for describing the characteristics of a 
TOTAL dataset. A dataset is a file of records in the 
TOTAL data base environment. It is a part of the 
data base and can be related to other datasets within 
the data base. 

Element Entity - 

The entity type for defining data that cannot be 
subdivided. An element is the basic building blocl< of 
data structures. It is the lowest level data entity in 
the hierarchy. A TOTAL data item is described to 
Data Catalogue as an element entity. 



Entity - 

A Data Catalogue component consisting of various 
categories of information. Entities are grouped into 
classes according to the type of information used to 
describe them. This information can include 
definitions, values, technical attributes, control 
information, usage data, structural definitions, and 
relationships. 

Entry - 

A discrete occurrence of an entity type in the 
Catalogue. 

External Resource Entity - 

The entity type used to define an information 
processing resource that is not accessible by 
computer. Relevant resources could be flowcharts or 
procedural instructions. 

Field - 

A unit of information in an entity definition. One or 
more fields are provided for each category applicable 
to an entity type. 

File Entity - 

The entity type for describing the characteristics of a 
file, which is a collection of one or more records that 
can be accessed and stored physically. A single file 
can contain several different types of records and 
many different records of each type. 

Form Entity - 

The entity type containing information related to a 
form used in the information processing cycle. A 
form is a document containing printed captions, data, 
and blank spaces that need to be filled with data. It 
can be a source for input data, or it can be partly the 
output of one Data Catalogue function and partly the 
source of another function. 

Function - 

A process that performs a specific type of operation 
for creating, maintaining, and accessing the 
Catalogue. The six Data Catalogue functions 
provided are Update, Query, Report, Generate, 
Convert, and Utility. 

Generate Function - 

The Data Catalogue procedure used to create source 
statement data definitions from information in the 
Catalogue. COBOL, PL/I, and TOTAL DBDL 
statements can be generated. 

Group Entity - 

The entity type for describing a logical collection of 
elements and subgroups. A group contains two or 
more subcomponents, which can be elements and/or 
other groups. A TOTAL element is described to Data 
Catalogue as a group entity. 

Hierarchy - 

-The rank or order of entity types recognized by Data 
Catalogue. An element entity is the lowest level in 
the hierarchy and a user entity is the highest level in 
the hierarchy. 
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Manual Task Entity - 

The entity type for describing an activity that does 
not involve any computer processing. Checking 
control totals is' a manual task. 

Module Entity - 

The entity type for describing a computer process 
that performs one or more discrete tasks. A module 
can be free-standing or part of a program. 

Procedure Entities - 

A class of entity types for describing the processes 
that perform a task and the resources required to 
complete the task. Procedure entities are one step 
up the hierarchy from data entities. Module, 
program, system, form, report, external resource, and 
manual task entity types are procedure entitles. 

Program Entity - 

Synonymous vi/ith module entity. A program can 
contain modules, call modules, or consist of one 
module by itself. 

Query Function - 

The Data Catalogue procedure used to interrogate 
the Catalogue. Entities can be counted, listed by 
Catalogue name, or listed in detail. 

Record Entity - 

The entity type for describing the characteristics of a 
record. A record is a logically associated collection 
of related elements and/or groups. 

Report Entity - 

The entity type for describing a formatted 
presentation of information that can be printed or 
displayed. A report is the end product of the 
information processing cycle and can be prepared 
manually or by computer. 

Report Function - 

The Data Catalogue procedure used to produce 
various reports based on information in the 
Catalogue. The reports are used for documentation 
and for analysis. 



Report Name - 

The name by which a category field is Identified on 
Data Catalogue reports. 

Request - 

A series of statements that identify the function to 
be performed and specify the requirements for the 
desired operation. 

Screen Entity - 

Synonymous w/ith Report Entity. 

■ System Entity - 

The entity type for describing an Information 
processing system. A system is a self-contained 
collection of one or more computer programs and 
ancillary manual tasks that perform a given function 
completely. A system contains processes that in turn 
access resources. 

System Name - 

The name specified by the user when entering or 
accessing a category field. 

Update Function - 

The Data Catalogue procedure used to maintain 
entries in the Catalogue. Entries can be added, 
changed, or deleted through this function. 

User Entity - 

The entity type for defining responsibility of a 
management unit for a given activity or resource. A 
management unit can be assigned responsibility for a 
system, a program, a manual task, a file, or an 
external resource. 

Utility Function - 

The Data Catalogue procedure used to initialize and 
support the Catalogue. This is a data administrator 
function. 

Version - 

A procedure or user entry that is established as a 
variation of another entry in the Catalogue. 
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